I would like to propose a change to the default retry logic. Currently, the retry logic is a static number based on number of retries. This might work for simple cases, but leads to a thundering herds problem.

Essentially, let's say that our requests failed because we made too many requests to the backend at once. We could get 5xx's from the server because of capacity. If we delay all requests by the same number, we are likely to get stuck in an infinite cycle of overloading the server.
Industry practice is typically to introduce jitter so that a request happens at a random interval between 10ms and the exponential time. This prevents the thundering herds problem.

As a more complex case, say that 20 different users get a webhook notification at the same time, and they all use tanstack query to hit the server api at the same time. Due to capacity issues, they all get 5xx's. Even if tanstack query is rate limiting for a single user, it can't do it across multiple clients. The clients will all fail, and will all "retry" at the same time, because they will all have the same static retry logic.

This PR proposes to change the default to a random interval from 10ms up to the existing exponential limit.

However, I realize that changing defaults like this can potentially lead to weird changes for users of the library, so I fully understand if this proposal gets rejected. I can always override the delay function for myself, but thought I would propose a better default if there is appetite. Thoughts?